Meridian Explorer security is very configurable, flexible, and powerful. It uses some concepts that are similar to Meridian Enterprise vault security and some that you may not be familiar with.
It is important to understand that Meridian Explorer security is not applied directly to folders like Meridian Enterprise security roles or Windows access control lists. This is because Meridian Explorer relies less on the folder paradigm than Meridian Enterprise or Windows.
All Meridian Explorer security is defined using BlueCielo users and groups that are members of defined roles. The users and groups can be defined in Meridian Enterprise Server or they can be mapped from Microsoft Active Directory as described in Mapping AD groups to BlueCielo groups.
Note Only a user’s name and not their domain determines their identity in Meridian Explorer. This is by design so that you can move the user account to a different trusted domain and the user will retain their security profile. Conversely, different users in separate domains that use the same account will have the same security profile. The domain name does not distinguish them.
The effective permissions for a particular user for a specific item are determined by these factors:
Following are explanations of each of these factors.
User roles
A user role is a set of users or groups with the same functional role relative to the organization, for example, Contributor, Reviewer, and Document Controller. Some example roles are predefined but you can edit and delete them and create others to meet your own requirements. You can assign a permission level to a user role at any level in a property hierarchy, which is explained below. Unlike with permission levels alone, user roles give you another dimension of flexibility to assign security, especially in complex environments or with many users.
Note We recommend that you assign only BlueCielo groups to roles, not individual users. This way, users can be given access to the repository by their group memberships. Security can then be adjusted in the group memberships instead of in the repository.
Permission levels
A permission level is a set of permissions that can be assigned to a user role at a level of a property hierarchy, for example, View, Manage, and Full Access. Some example permission levels are predefined but you can edit and delete them and create others to meet your own requirements.
Property hierarchies
A property hierarchy is how security can be assigned based on property values. Separate hierarchies can be defined for documents and for tags. Each hierarchy can comprise multiple levels. Each level corresponds to one property. In this way, Meridian Explorer property hierarchies are similar to the Meridian Enterprise Field-Path definition. That is, a document's folder location in the vault depends on its values for the properties that comprise the Field-Path definition. In a Meridian Explorer property hierarchy, a user's effective permissions for an item depend on its values for the properties that comprise the property hierarchy.
One difference is that Meridian Explorer property hierarchies are invisible and have no direct relation to folders, as previously stated. Therefore, they affect any navigation views (that can have different hierarchies) that also use the same properties. This greatly extends the power of property hierarchies. Another difference is that security can be configured even more granular by assigning different permission levels to user roles for any number of values of the same property in a hierarchy. This allows you to configure a single security model made up of numerous rules that apply everywhere in the repository regardless of whether the documents, tags, or property values already exist.
At each level of a hierarchy, you can assign a permission level to one or more user roles. You can also not assign any permission level to a user role, which basically prevents the users in that role from performing the activities that correspond to the permission level . Moreover, each level of a hierarchy can either have its own permission level assignments or it can inherit the assignments of its parent property in the hierarchy. This is true even if items have no value for the property—they will inherit the parent permission level until a value is explicitly set for the property, at which time any assigned permission level will take effect. A user’s effective permissions for a particular document, tag, or project are the sum of the permissions that are assigned to the roles for which the user is a member. These permissions apply regardless of whether the items reside in projects or not.
Global permissions
Global permissions are exceptions to the permission level assignments just described. These permissions do not involve user roles or property hierarchies. They control the same permissions (and more) as property hierarchy assignments but override them. Global permissions can be granted to specific BlueCielo groups. This can be valuable so that some users (for example, system administrators) can manage items in the repository regardless of where a document resides in the repository or its property values (which define the item level security). For that reason, global permissions should be assigned sparingly.
Project permissions
Most Meridian Explorer users only need access to the master documents (or renditions of them) in a repository. They are secured by the property hierarchy security model described above. But if some users also need access to work-in-progress documents that reside in projects in the repository, an additional security level is often needed. Project permissions are that extra security level.
Project permissions apply only to the project containers and not to the items they contain. Examples of these permissions are the ability to view projects and manage the security of projects. Project permissions can be assigned to specific user roles and are in addition to the item level security that applies to all documents and tags. This allows you to grant project access only to certain roles and project management responsibility only to other roles. Project permissions can apply to all projects in the repository or, if you need even more flexibility, they can be overridden for particular projects as described in the BlueCielo Meridian Explorer User's Guide.
Working with these concepts to configure repository security is described in the following topics.